Due to the tremendous success of the Internet, it has become a challenging task to make use of the Internet Protocol IP (see, e.g., Jon Postel, Internet Protocol, DARPA RFC 791, September 1981, incorporated herein by reference) over all kind of links. However, because the IP protocols were designed for wired links with high bandwidth capabilities, and because packet headers of the IP protocols are rather large, it is not always a simple task to use IP protocols with narrow band links, for example cellular links. If we consider the scenario when the IP protocols are used for real-time data, for example ordinary speech, the User Datagram Protocol UDP (see, e.g., Jon Postel, User Datagram Protocol, DARPA RFC 768, August 1980, incorporated herein by reference) and the Real-Time Transport Protocol RTP (see, e.g, Henning Schulzrinne, Stephen L. Casner, Ron Frederick and Van Jacobson, RTP: A Transport Protocol for Real-Time Applications, IETF RFC 1889, IETF Audio/Video Transport Working Group, January 1996, incorporated herein by reference) are applied on top of IP. Together they require a total amount of 40 header octets (IP 20, UDP 8 and RTP 12 octets). If we combine these header requirements with ordinary speech usage, which may have frame sizes as low as 15–20 octets, the header part will disadvantageously represent more than 70% of the packet.
The term header compression (HC) comprises the art of transparently minimizing the necessary bandwidth for information carried in headers on a per-hop basis over point-to-point links. Header compression takes advantage of the fact that some fields in the headers are not changing within a flow, and that most header changes are small and/or predictable. Conventional header compression schemes make use of these facts and send static information only initially, while changing fields are sent either as uncompressed values (e.g., for completely random information) or as differences (or deltas) from packet to packet, the latter typically referred to as difference (or delta) encoding.
Conventional header compression/decompression schemes are often realized using state machines, and the challenging task is to keep the compressor and de-compressor states (or contexts) consistent with each other.
In general, there are two different conventional techniques to keep the de-compressor context updated. The first technique uses periodic refreshes wherein absolute header data is sent. An advantage of this solution is that its performance is not affected by the round-trip-time (RTT) of the link, due to the fact that no messages are sent from the de-compressor to the compressor. This means that it also works over simplex links. On the other hand, there are a number of disadvantages with periodic refreshing. For example, the average header overhead will be high due to the high number of large refresh headers, most of which are unnecessary. On the other hand, if the header refresh rate is too low, the number of lost packets will be high if errors on the link are common.
The other common way of keeping the context updated is to let the compressor send refreshing information (i.e., absolute header data) only when requested by the de-compressor. This requires a duplex link but reduces the average header overhead because no unnecessary updates are performed. Provided that the RTT is small, this solution also reduces the number of lost packets due to inconsistent context states after a link error. Due to the fact that several header fields change on a packet-to-packet basis in real-time traffic (e.g., real-time speech), this solution is preferable for real-time applications. The obvious disadvantages are dependence on the back channel of the duplex link, sensitivity to lost packets on the link, and the high number of consecutive lost packets that will occur in case of an invalid context (and associated refresh request) when the RTT is high.
For all header compression schemes, two measures describe their performance. Compression efficiency describes how much the headers are compressed. This can be expressed by the average or maximal header size, combinations of both, or in other ways. Robustness describes how well the scheme handles loss on the link. Will loss of a packet make the header contexts inconsistent resulting in a large number of subsequent lost packets?
Thus, header compression schemes seek a balance between compression efficiency and robustness. More robustness requires more header overhead, while more efficiency results in less robustness. Efficient schemes therefore typically have some weakness in their robustness, meaning that context updates on request are needed.
Currently, there exist a number of different conventional header compression schemes. In fact, they are not really different schemes but different development states of the same one. The earliest proposals (see, e.g., Van Jacobson, Compressing TCP/IP Headers for Low-Speed Serial Links, IETF RDC 1144, IETF Network Working Group, February 1990, incorporated herein by reference) handle only compression of TCP (see, e.g., Jon Postel, Transmission Control Protocol, DARPA RFC 761, January 1980, incorporated herein by reference) flows, while ideas have later evolved to make compression of UDP and also RTP headers possible (see, e.g., Mikael Degermark, Björn Nordgren and Stephen Pink, IP Header Compression, IETF RFC 2507, IETF Network Working Group, February 1999, incorporated herein by reference; and Steven Casner and Van Jacobson, Compressing IP/UDP/RTP Headers for Low-Speed Serial Links, IETF RFC 2508, IETF Network Working Group, February 1999, incorporated herein by reference).
There are also new proposals like the ROCCO scheme (Lars-Erik Jonsson, Mikael Degermark, Hans Hannu, Krister Svanbro, Robust Checksum-based Header Compression (ROCCO), Internet Draft (work in progress), October 1999, incorporated herein by reference) under development for increased robustness. Up until now, little attention has been paid to context update procedures. The methods used have usually been very simple and unsophisticated. One of the reasons for that is probably that these procedures in general are not subject to standardization. Also, context updates on request have been considered only as fall-back solutions. However, when header compression is used over error-prone links with long round-trip times and for data with real-time requirements, sophisticated context update procedures would make significant improvements to the performance.
It is desirable in view of the foregoing to update an invalidated decompressor context as fast as possible with a minimal increase in header overhead. This can be divided into five parts: (1) when to start sending update requests; (2) how to make sure that update requests are delivered to the compressor; (3) what to include in update requests; (4) how to react to update requests received at the compressor side; (5) how to make sure that context updates are delivered to the de-compressor; and (6) how to verify a correct context.
The invention provides for relatively fast and reliable context updates with relatively low overhead by; sending anticipatory context update requests before decompressor context invalidation is detected; sending redundant context update requests; and sending redundant context updates. Transmission parameters associated with both update requests and updates can be controlled appropriately to improve their chances for delivery, and needless update requests can be identified and ignored at the header compression side.